移除 runtime 的 max_loops 限制并同步 compact 语义#292
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
| return err | ||
| } | ||
|
|
||
| for { |
There was a problem hiding this comment.
Removing the loop budget turns the run loop into an unbounded execution path. If the model keeps returning tool_calls, this can run indefinitely (unbounded tool invocations/token spend/session growth) until external cancellation. Please keep a hard safety guard (for example a per-run max-turn fail-safe, or a separate safety budget) even if max_loops is removed from user-facing config.
| @@ -25,7 +25,6 @@ type persistedConfig struct { | |||
| SelectedProvider string `yaml:"selected_provider,omitempty"` | |||
There was a problem hiding this comment.
max_loops was removed from persisted config while strict YAML known-fields decoding is still enforced, so existing user configs containing max_loops now hard-fail to load. If this breaking change is intentional, consider adding a temporary compatibility shim (accept+ignore legacy key) or an explicit migration path in docs/release notes to avoid upgrade-time boot failures.
背景
当前测试分支需要去掉 runtime 的
max_loops限制,避免 ReAct 主循环在固定轮数后被 runtime 强制中断。这次改动同时清理了围绕
max_loops和loop_limitcontinuation checkpoint 的实现、配置、测试与文档,避免仓库中继续保留已经失效的配置项和语义说明。变更
runtime.Run()中的max_loops终止判断loop_limitcompact mode 及相关 continuation checkpoint 逻辑config/ YAML 持久化中的max_loops配置项max_loops/loop_limit的旧测试reactive compact的多次降级重试语义max_loopsloop_limitreactive compact最多 3 次降级尝试影响
config.yaml中如果仍包含max_loops,现在会按未知字段报错compact现仅保留manual、auto、reactive三种 mode验证
go test ./internal/runtime ./internal/config ./internal/context/compactgo test ./...